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COMMENTS ON 
"PROPOSED REMOTE JOB ENTRY PROTOCOL" 


Chuck Holland’s draft proposal (RFC #360) is an excellent 
document, very complete and consistent. Since the final standard RJE 
protocol will be widely used on the Network, honing its definition now 
will save trouble and discontent later. Therefore, I will proceed to 
make a new suggestions and pick a few nits. 


1. In my humble opinion, the command verb "BYE" is overly 
cute; I would find "QUIT" much less offensive 


2. The "(pathname)" syntax (p.5) may need some reworking. 
It would be very desirable for all protocols or Network 
access programs to use the same syntax for selecting a 
host and socket and/or file name. (Note that the FIP 
documents use the term "pathname" in the more 
restricted sense of a local file system name.) 


a. The PORT construction seems very undesirable, 
since it depends upon a particular bit convention 
of TIP’s. TIP’s have bent Network protocols rather 
badly in the past, but surely we don’t want to build 
their particular socket system into an official 
protocol. 


b. For convenience, it may be desirable to allow hex 
and octal socket numbers. 


c. There will probably be other hosts besides TIP’s which 
will use the "(host-socket)" pathname, and some of 
them may want a transmission attribute other than "T". 
The proposed syntax should be changed to allow (attributes) 
in (host-socket) 


d. I see no reason to exclude attribute "TE", since the control 
characters cr, lf, and ff exist in EBCDIC as well as ASCII. 


e. There are many EBCDIC codes, and at least 2 ASCII’s. The 
(code) construction needs expansion. 
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The syntax of OUT might reflect the fact that pathname is 
required only for (disp) of "(S)". 


It may be desirable to distinguish syntactically (job-id) 
and job-file-id). For example, this would allow the command 


ABORT (job-file-id) 
to abort the job currently being transmitted, regardless of 


its id (this assumes that multiple jobs for a given user 
are sent sequentially). 


The replies presented in the document are very good, but may 
need some elaboration. For example, the syntax error messages 
should be more specific. When the user enters: 


OUT=(H) UCLA91: NE/ARP998.WGW.TEST 


he would like the error message to indicate explicitly that 
the hostname is not valid, rather than merely being told there 
is something wrong with one of the parameters. 


Experience with remote job entry to CCN via the Network has 

shown that the user wants a transmission status command, to 

find out how many records have been sent or received so far. 

The network bandwidth corresponds in order of magnitude to 

one page per second. The average output for jobs submitted 

to CCN from the Network has contained about 30 pages, so 
significant transmission delays are not unusual. It is important 
to add a command for this purpose. 
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